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ENTERPRISE RESOURCE PLANNING BASED ON SEPARATION OF 
PERCEPTION AND DATA 

FIELD OF THE INVENTION 

The present invention relates to enterprise resource planning. More particulariy, it 
relates to a new approach to databases, introdudng a novel concept for databases, and 
method of their use thereof. 

BACKGROUND OF THE INVENTION 

Managerial infonmation is commonly handled by enterprise resource planning 
(ERP) software packages. These are database-driven tools that are heavily customized 
for the specific use of a given customer, or at least for a highly defined customer 
discipline. As a result, most of the essence of the customer's managerial information 
pattern is embedded at the code level. Since this pattern is the result of 'soft' algorithms, 
and since the number of managerial solutions for a given problem is more than one, 
organizations tend to be characterized by a rather complex model with a relative large 
number of degrees of freedom. 

Traditionally, developing ERP applications at the code level to accommodate the 
customer pattern generally results in intricate and highly expensive solutions. 
Furthermore, these solutions tend in most cases to represent the perception of the 
programmers (usually these programmers are not members of the customer's 
organization) who are tailoring the ERP platfonn for the customer, ratiier than the 
perception of the customer's own infomriation technology (IT) manager. In any event, the 
tailoring is usually so specific ttiat any subsequent unanticipated evolution of the 
customer organization requires reopening of the code, sometiiing most programmere 
consider impractical. In conclusion, as much as an organization requires an ERP tool for 
achieving better perfonnance, the organization is dependent on extemal expert tailoring 
of the ERP tool and is compelled to freeze development of the tool at ttie point where the 
tailoring was completed. 

Furthennore, ERP systems are not geared to support human mistakes, therefore 



1 



wo 2006/016350 PCT/rL2005/000693 



2 

they cannot be used as a conceptual aid for a learning manager. Thus, the traditional 
ERP hinders the development of the modem idea of a teaming organization. 

To achieve an improved ERP, It is necessary to reevaluate the nature of 
managerial information, which is what ERPs are designed to help manage. An analysis 
5 of managerial infomnation reveals a complex mixture of two modes of infonnation: raw 
data and perceptions (or concepts) applied to data. While the common prac*ce is to 
ignore the differences between the two modes of infonnation, it is our opinion that ttie 
undistinguished approach to this mixture in ERP tools is Uie underlying cause of the 
tools' limitations in both the technical and ttie managerial sense. One should appreciate 

10 ttiat raw data is kept pretty much constant along fhe lifespan of the organization, 
managerial perceptions, on ttie other hand, reveal considerable variation witti changes 
of personnel and with the development of the organization over time. Hence, these two 
modes of infomnation, raw data and perceptions, are of an utteriy diverse nature. In fact, 
ttiey actually constitute two independent dimensions of ttie infonnation body, witiiin 

15 which they co-exist. By contrast, traditional ERP storage of data in flat tables is a 
reflection of a mdimental one-dimensional approach to information processing wherein 
oOier features are handled at the code level. Therefore, while ERP systems provide 
good and reliable means of raw data manipulation at the customer level, system 
modification to accommodate changes in the customer's perception of how his business 

20 is organized must be done at the programmer level - in other words, beyond the reach 
of the ordinary organizational personnel, such as tiie most natural candidate for the job, 
the organization's IT manager. 

Applying human characteristics to mechanistic constraints is vwdely approached 
in the artifidal intelligence wori< done in association with efforts to render robots witti 
25 signal perception and environment perception. Two disciplines are largely considered in 
approaching these goals. These are fuzzy-logic, which is meant to challenge marginal 
uncertainty, and neural networicing that is aimed at rendering computing devices a grasp 
of systematization. 

While others have already pointed out that infonnation includes perceptual 
30 components, this notion has not trickled into the realm of databases, particulariy to ERP 
products. We, offer, for ttie first time, a mechanistic definition and real apparatus that 
enable ttie automation of human perceptual features with regard to infonnation. It is 
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achieved by defining a minimal set of database features, which are sufficient for the 
detenmination of the perception component of managerial infomnation. These features 
support: 

The hierarchical and nested tree arrangement of perceptual items. 

5 Automatic preservation of, and accessibility to, past states of the perceptual 

trees. 

Unlimited sequential assodation between any infomnation item, and its element 

Rendering each information item sufficient linl^s that systemization is conceivable 
from any relevant point of the infomnation body. 

10 Ad Hoc intra-organizational assodatlon-disassodation of the trees. 

Attenuation of linguistic ambiguity, while maintaining multi-linguistic capability, 
including the establishment of organizational nomenclature. 

It is a system that is readily capable of adaptation to conceptual alteration, be it a 
result of human mistakes or the fruits of a learning procedure. As such, it becomes 
15 automatically an instalment for depicting the past states of the organization. Hence, It 
provides the user with an ever growing sense of self, as well as a record of 
organizational experience. Other individuals may follow the evolution of the organization 
by accessing the perceptual trees at various previous points in time. 

The dynamic nature of the hierarchical trees not only registers the user's 
20 perception, it can be easily used as an organizing aid in the construction of a new 
concept. 

Organizations may gain, as well as share, perceptual knovftrtedge with peer and/or 
supervisory organizations by association and disassodation of their relevant conceptual 
trees. "Knowledge" is considered by the inventors as tiie contexture of property 
25 associated perceptions, and is tine tiiird layer In tiie hierarchal series where "raw data" is 
ttie lowest, followed by "perception", "knowledge" and finally rises to ttie degree of 
"intelligence". 

In this way governmental and regional organization may gather and distribute 
infomiation and data with affiliated organizations. In cases where a large body of 
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perceptual information is needed for the proper functioning of an organization, (e.g., in 
the fields of education, health care, legal precedents, etc.), tree sharing enables 
automatic joint endeavors of knowledge construction. This joint product is concomitantly 
available to all tree sharing organizations. 

5 Accordingly, several objectives and advantages of the present invention are: 

An ERP method and system that enables the automation of human perceptual 
features with regard to infomiation. 

An ERP method and system that is programmable at the user-level, requiring 
only a familiarity with a rather limited vocabulary. ^ 

10 An ERP method and system that provides view of the organization's knowledge 

at any point in its history. 

BRIEF DESCRIPTION OF THE INVENTION 

15 There is thus provided, in accordance with some prefen^ed embodiments of the 

present invention, a method for a universal Enterprise Resource Planning (ERP) 
information management suitable for any organization, the information separated into 
raw data and at least one of a plurality of subjective perceptions attached to it, the 
method comprising: 

20 organizing Infomnation into tables of three types: 

entity table for raw data, 

tree table for perception , 

collection table for many-toHfnany assodations, 

manipulating the information according to a set of predetenmined parameters that 
25 constitutes meta characteristics of the infomiation, using a set of macros 

to perform operations. 

Furthermore, in accordance with some preferred embodiments of 
the present invention, the tables comprise a database. 
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Furthermore, in accordance vwth some pnefenBd embodiments of 
the present invention, entity table comprise administrative fields, whid) 
record Inheritance. 

Furthennore, in accordance with some preferred embodiments of 
5 the present invention, entity table comprise administrative fields which 

record reciprocal pointing relations. 

Furthermore, in accordance with some prefen^ embodiments of 
the present invention, entity table comprise administrative fields which 
record Interface implementations. 

10 Furthermore, in accordance with some prefen^ed embodiments of 

the present invention, entity table comprise administrative fields which 
record affiliation to an echelon of the organization. 

Furthennore, in accordance with some prefenned embodiments of 
the present invention, entity table comprise infomiative fields for raw data. 

15 Furthennore, in accordance with some preferred embodiments of 

the present invention, tree-table comprise records defining tree-nodes. 

Furthermore, in accordance with some preferred embodiments of 
the present invention, tree-table comprise multi-lingual fields. 

Furthennore, in accordance with some preferred embodiments of 
20 the present invention, one of the multi-lingual fields relates to a 

nomenclature of the organization. 

Furthennore, in accordance with some prefenned embodiments of 
the present invention, tree-nodes comprise fields relating to tracking of 
evolution of the tree-nodes. 

25 Furthermore, in accordance vwth some prefenred embodiments of 

the present invention, tree-nodes comprise fields relating to 
compartmentalization. 

Furthennore, in accordance with some prefenred embodiments of 
the present invention, tree-nodes comprise fields relating to one or many 
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entity or collection records. 

Furthemnore, in accordance with some preferred emt)odiments of 
the present invention, tree-nodes comprise fields relating to tree-node to 
tree-node association and/or disassodatlon. 

Furthermore, in accordance vWth some preferred emt)odiments of 
the present invention, tree-nodes comprise fields relating to a cascade of 
tree-nodes and thereafter relating to their related tree-nodes and/or entity 
records and/or colledion records. 

Furthemnore, in accordance with some prefenned eml)odiments of 
the present invention, colledion table comprises administrative fields 
holding one-to-one relations between records. 

Furthemiore, in accordance with some preferred embodiments of 
the present invention, collection table comprise administrative fields 
holding one-to one relation between a record and a value. 

Furthemiore, in accordance with some prefenred embodiments of 
the present invention, collection table comprise administrative fields which 
record reciprocal pointing relations. 

Furthemiore, in accordance with some prefemed embodiments of 
the present invention, the set of predetermined parameters comprises 
one or more tables. 

Furthemnore. in accordance with some prefenred embodiments of 
the present invention, the tables comprise a database. 

Furthemnore, in accordance with some prefenred embodiments of 
tine present invention, the set of predetermined parameters is modifiable. 

Furthemnore, in accordance with some prefenred embodiments of 
the present invention, the set of predetermined parameters that 
constitutes meta characteristics is stored in a kemel, 

Furthemnore, in accordance with some preferred embodiments of 
tiie present invention, tiie set of predetemnined parameters that 
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constitutes meta characteristics of entities. 

Furthennore, in accordance with some preferred embodiments of 
the present invention, the set of predetemiined parameters that 
constitutes meta characteristics of fields, 

Furthemnore, in accordance with some prefen^ embodiments of 
the present Invention, the set of predetermined parameters that 
constitutes meta characteristics of collections. 

Furthemnore, in accordance with some prefen^ed embodiments of 
the present invention, the operations also include funcHons. 

FurthemDore, in accordance with some preferred embodiments of 
the present invention, the operations include automatic operators that 
create or modify tables and further meta characteristics using a 
predetermined editor. 

Furthennore, in accordance with some preferred embodiments of 
the present invention, the operations dynamically create automatic input 
fonns and/or output reports in accordance with the meta characteristics. 

Furthemiore, in accordance with some preferred embodiments of 
the present invention, the automatic input forms include a 
contracting/expanding tree. 

Finally, in accordance with some prefened embodiments of the 
present invention, the operations dynamically guard validity of data In 
accordance with the meta-characteristics. 



25 

BRIEF DESCRIPTION OF THE FIGURES 

The invention is described herein, by way of example only, with reference to the 
accompanying Figures, in which like components are designated by like reference * 
numerals. 



7 



wo 2006/016350 



PCT/IL2005/000693 



8 

FIG, 1 illustrates a core of an ERP application system based on 

separation of perception and data, in accordance with a prefen^ embodiment of the 
present invention. 

FIG. 2 illustrates Fixed Columns, in an exemplary ERP application, in 
5 accordance with a preferred embodiment of the present invention 

FIG. 3 illustrates Meta-Definitions of tables, in an exemplary ERP application, In 
accordance with a prefemed embodiment of the present invention. 

FIG. 4 illustrates Meta-Definitions of columns, in an exemplary ERP 

application, in accordance with a preferred embodiment of the present invention. 

10 FIG. 5 illustrates a module of an ERP application in accordance with a 

prefened embodiment of the present invention that was designed for Tel-Hai College, 
showing several perceptual approaches to the same set of data (in this case space 
management). 

FIG. 6 illustrates a core of an ERP application system based on separation of 
15 perception and data, in accordance with a prefeoed embodiment of tiie present 
invention, suitable for adaptation for any organization, witti Oie addition of 
compartmentalization core. 

FIG. 7 lllustirates a module of an ERP application in accordance with a 

prefenred embodiment of the present invention that was designed for Tel-Hal College 
20 marketing deparbnent. 



DETAILED DESCRIPTION OF THE INVENTION 

25 The present invention is directed to a data processing system and mettiod for 

use in enterprise resource planning (ERP). 

The present invention is based on the realization that Information, such as 
information about an enterprise's resources and management, has two main 
characteristics: impartial raw data and how that raw data is subjectively perceived by a 

8 
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particular individual or organization. 

As an example consider an educational organization such as a college. The 
college administration has to allocate classrooms and other types of building spaces for 
classes and other activities. A classroom may be defined as a walled space, but for a 
teacher not every walled space can serve for classes {for example storage rtx>ms, 
hallways, etc.). however for the maintenance staff, all walled spaces must receive the 
same upkeep, and for them a "classroom" has the same meaning as a "storage room". 
In other organizations same term may be assigned an utterly different meaning. 

In other words, same raw data has different perceptions attached to it by different 
organizations. Moreover, same raw data (like Vailed space") has different perceptions 
attached to it by different people of the same organization, 

A main aspect of the present invention, in view of the above realization, is the 
novel separate treatment of the different aspects of information. The present invention 
deals with the arrangement of rational database by way of structure and function in a 
manner that takes into account the different aspects of raw data and its variety of 
corresponding perceptions, and based on that database arrangement a novel Enterprise 
Resource Planning (ERP) application (sometimes refenred to. in ttiis specification, as 
PerDB) is introduced. 

This perceptual database serves as tiie basis of a generic ERP application. 
Whereas usually an ERP application is specially tailored by programmers to a specffic 
client's needs, ttie ERP application of the present invention is provided as a general 
framework, that each client can adapt himself to his organization's unique and dynamic 
needs. Hence, the balance of resource requirements is shifted from programming to 
characterization. In this way, ttie present invention promotes leadership in management 
since the emphasis in the customization phase should focus primarily on appropriate 
mechanization of ttie organization's structures, procedures and rules (in-house or 
extemal technical help from IT professionals may be needed to set up a customized 
system). 

The perceptual database of the present invention can be implemented in many 
ways, as will be apparent to one skilled in ttie art. In a prefenBd embodiment, it is 
implemented in at least ttiree sets of tables (tree, entity, collections -explanation 

9 
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hereinafter). 

In accordance with a prefenned embodiment of the present invention, a set of 
general principles may be summarized as follows: 

(1) Infonmation is comprised of objective Raw-Data coupled to Subjective 
5 Perception{s). 

(2) Data may be coupled to an unlimited number of Perception(s). 

(3) Data is approached (/.e., reading or writing) only via a Perception. 

(4) Data is acquired only by predetenmined Input-Procedures (see Input 
Procedures Tree T002, FIG. 1) by Automatic Fomris. 

10 (5) Since Data Is coupled to Input Processes, which are in tum triggered by 

known Events, Data and Events are tightly associated, to the extent that recorded data 
illustrates unequivocally its generated events. 

(6) Analysis of Data is subject to predetemiined, yet adaptable, Output 
Procedures (see Output Procedures Tree T003. FIG. 1) by automatic fornns. 

15 (7) Perception is subjective (pertaining to an individual, or a group) and 

evolvable by teaming. 

(8) The basic topology of a perception is depicted by the Perceptual-Tree 
table, comprising of an Infinite nested generations of Tree-Nodes (i.e., records of the 
Perceptual-Tree table), 

20 (9) Perceptual-Trees specificity character implies that the properties of a 

Tree-Node trickle down to its children tree-nodes, till new properties are attributed to a 
down stream Tree-Node, which start a new set of properties trickling to its own children 
tree-nodes. 

(1 0) Data is stored in Instances, which are records of Entity tables. 

25 (1 1 ) A complex Instance may be composed of various Instances that maintain 

a certain inheritance relation among themselves as defined by the Entity-Inheritance- 
Tree (see Person Card E025 and Personal Items E026 tables, FIG. 6). 

(1 2). Perceptual-Trees and Entities may inti^link by pointing one at either itself. 
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or interlink by pointing at each other. Single-to-plural pointing is feasible by Collection 
tables comprising of Joint records. 

(13) Each Instance item holds knowledge of all relevant data items (Tree- 
Node, Instance or Joint) that are pointing at itself. Thus, all relevant infonnation, 

5 pertaining to.a given Instance, may be reconstituted from any point of the data body. 

(14) Cross effects on different field values may be achieved by Macros 
embedded in the field's meta-features. 

(15) Accessibility is denied by default to everyone. It is open only to 
predetermined memt>ers (actors) of the organization. 

10 (16) A user is granted accessibility to infonnation by specific (see Tree 

specificity) matching of tiiree orthogonal attributes (DataSec, short for data section, Ae., 
a reference to the nature of ttie data, SubOrg, short for sub-organizational unit, i.e., a 
reference to an affiliation to an organizational echelon, and Action Privileges) with the 
two con^esponding orthogonal DataSec and SubOrg flags that are cam'ed by each 

15 infonnation item. 

The enterprise resource planning application based on separation of perception 
and data is conceived according to a mechanistic model wherein understanding of 
knowledge of an enterprise is implemented at three levels of information management: 

(A) definition and storage of raw data 

20 (B) perceptual approach to data 

(C) infonnation-networking as tiie basis of knowledge 

Raw data is defined as data items comprising details at the utmost 
required/relevant resolution. The anrangement of these data items must maintain at all 
times independence of each item from every other item, from its usage, and/or its 
25 interpretation. 

Raw data has to be stored in such a way that it will be globally retiievable. 
Infonmation Security is achievable by a two-phase matching mechanism. On the first 
hand, each data element (i.e.. Entity field or Tree-Node) is a priori imprinted by the two 
orthogonal dimension flags: DataSec and SubOrg. By that a data element cam'es one 

11 
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attribute to its data-nature, as by the organizational perception displayed in Data Section 
Tree T006 (see FIG 1), and a second attribute to its affiliation to the appropriate 
organizational echelon, as by the Org Manning Tree T006 (see FIG 1). The other phase 
of the matching mechanism requires that retrieving agents should carry proper 
5 accessibility keys, i.e., the three dimensions: DataSec, SubOrg and Aciion Privileges, 
the latter should be appropriate for the adequate handling of the desired data. In other 
words in order to be allowed to canry out a certain action on a spedfic data, a user must 
posses full matching of DataSec and SubOrg flags with the corr^ponding flags 
associated with that specific data as well as Action Privilege that allows him to cany out 
10 that action. 

Most people cannot relate to an Impartial data but by assigning it a verbal name. 
Most people will refer, in any practical conversation, to a plane of wood, about one 
square meter in area, attached to four legs of 75 cm in length as a "table". However, 
"table" is merely a common layman's interpretation. That is so, since on one hand, no 
15 craftsman is capable of reconstructing a "table" unless real materials and measures are 
specified, and on the other hand, the same structure can be put to use as a base for a 
statue, as a spacer, as a door banicade, or various other functions. Yet, no matter how 
this item would be refenred to, it will always comprise raw data: a certain plane of certain 
matter with certain four legs. 

20 Verbal naming has been historically the most fundamental and unavoidable first 

level perceptual attribute to data. Yet, one should be aware that naming is naturally 
subjected to a certain ambiguity, the degree of which is largely dependent of the 
speaking-language used. Furthemriore, it is empirical experience that a given body of 
raw data may be perceived differently by different people of different nationalities. On top 
of that, information communication between humans is frequently complicated by 
differences in linguistic Interpretations of parallel verbal themes. In short, perceptual 
usage methods must accommodate cress-cultural management. 

It should be appreciated that unlike computerized retrieval engines, which may 
locate a data item directly at its register, the human approach to infonnation, raw data 
included, is canled out first via its perceptual tag, generally, by Its verbal name. 
Moreover, perceptions of a given body of (unvarying) raw data are most probably 
changing continuously as knowledge advances. 
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The average human psychophysical capability of simultaneously handling a very 
limited number of independent pieces of infomiation, forces us to think with the aid of 
grouping mechanisms (e.g., stereotyping, generalization, encapsulation, etc.) to which 
verbal tagging is usually assigned. Wrth time the groups themselves are considered as 
5 information. 

Perceptual confrontation with complex systems made up of a large number of 
items is achieved by means of categorization. If s a method of hierarchically tagging 
items with common denominators into groups that are themselves gathered into supra- 
groups based on meta-common denominators, and so forth. It has been employed as a 
1 0 taxonomical systematization method in almost every scientific discipline, and is the basis 
for database navigational engines. Hence, hierarchical tiees are one leading concept of 
tile perception component of information. 

Coping with the perceptual dimension of information is accomplished 
mechanistically by perception-tinee structures which maintain four intiinsic stiuctural 
15 degrees of freedom (apart from the organizational parameters, such as security): 

(A) Reduction of verbal ambiguity to a minimum. 

(B) Maintaining a flexible hierarchical nested tiee arrangement 

(C) Tracking tiie evolution of the perception with time. 

(D) Tracking the ownership of the perceptual tree, 

20 Linking inherentiy independent facts (raw data) and perception trees to a 

common metaphysical superstructure, usually referred to as the Vhole picture", 
constitutes an individual's comprehension, whereas further association of information 
into larger superstructures constitute knowledge. The ability to render infomiation 
stmctures the capability of being adequately inter-assodated (i.e., linking) is the 

25 mechanical basis for transforming data and perceptions to a sophisticated body of 
knowledge tiiat should aid organizational personnel in building comprehensive system 
perceptions, as well as aiding them with the tough job of decision taking. 

The potential for interlinking infomiation is embedded in all components of the 
present invention. Raw data tables may include pointer fields which register an 
30 expansion of data. It may be a single data item of an orUiogonal {i.e., to the table's entry 

13 
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dimension) nature, or a collection of data elements. A data field may point at a 
perceptual tree element whenever it refers to a grouped meaning of variant Infomiation 
perception, which in turn may point at any other data or collections of data. 

Perceptual tree items are obviously expected to point at raw data, for which they 
serve as perceptual entry pcMnts for human l)eings. However, the same perceptual items, 
may associate themselves with other perceptual items that are mounted on either the 
same or completely separate perceptual trees. These are the means for endowing a 
system with multi-<limenslonal aspects. For instance, space management at Tel-Hai 
College involves the perceptual construction of campus, buildings and rooms (see table 
Vailed space tree" T100 in FIG 5). From a different perspective (maintenance dept.) a 
different perceptual tree is constructed (see table "space maintenance tree" T601 in FIG 
5), pointing at the same set of data entities. Yet another perspective (this time for the 
purpose of allocating spaces with accessibility to handicapped persons) may involve the 
construction of a third perceptual tree (see table "affiliated levels" T600 in FIG 5), that 
points at branches of the original perceptual tree (T100), and through its nodes, pointing 
at the same set of data entities. 

the therapeutic effect of a drug, which by itself is a member of a medication tree, 
is associated with the disease tree, with the HMO financial tree, and with the malpractice 
hazard tree by a non-linear series of pointers. Certainly the Inter-linking of these trees is 
a crucial feature in conceiving the body of knowledge necessary for a properly informed 
real-worid medical decision. 

Finally, while inter-organizational sharing of infomiation is a key element in 
maximizing knowledge within the organization, it can at times detract from healthy 
competition or the organization's self-esteem. Accordingly, while the present Invention 
enables peer organizations to seamlessly associate their perceptual trees, it also 
enables them to disassociate the linkage at will. Intra-organizational accessibility of the 
perceptual trees is unaffected by inter-organizational association ordisassociation. 

The inventors of the present invention suggest defining a so-called "perceptual 
database" (or PerDB for short), separating data finom perception, and providing an ERP 
application that is in fact a basic fi^mewori^ into which any organization may pour its 
contents, environment and concepts, thereby being equipped with all necessities for 
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building its own ERP application without the help of external programmers. Technically 
PerDB serves as an interpreter of objects (i.e., a series of specifically defined tables, 
which will be elucidated thereafter) and engines whose data is indifferently embedded in 
any ordinary relational database. 

PerDB utilizes the database merely for data storage and retrieval, and does not 
define or use database diagrams, table relationships or other high-level performance 
tools. Relational diagrams and links between data entities (tables) that are commonly 
imprinted in the particular code of specific applications are, in the present invention, 
dealt with by PeriDB interpretation of meta-data (stored in specific, yet, ordinary entity 
tables) according to object oriented guidelines as explained hereinafter. By doing so, the 
present invention becomes independent of the specific database platform (examples of 
platfomis include: MS^SQL, Oracle, DB2 and others). 

"Inheritance", "polymorphism", "encapsulation" and "Interface implementation" 
are considered as fundamental characteristics of object oriented programming, whereas 
they are completely absent from conventional relational databases. In the present 
invention, however, these characteristics are introduced into PerDB. 

Inheritance is a way of expanding the definition of a previously defined base 
entity to create a new entity, which defines a "is-a" relation between the base entity and 
the inheriting entity, e.g., a rocking-chair is a chair, therefore inherits properties common 
to all chairs. Inheritance allows reuse of code. 

In the past (we refer to relational database programming), the definition of the 
rocking-chair table had to include the definition of the chair-table and any other 
definitions of higher base tables. 

In the present invention, PerDB implements the "is-a" relation based on meta- 
level definifions. Consequently, the data elements of the base tables needs not to be 
repeated for reuse. 

Polymorphism is a way of relating to a group of varying entities by their common 
properties, as these are defined in their common base entity, e.g., a rocking chair, a 
wheel chair and a stool are all chairs. 

In the past, each variant of the chairs was represented by a separate table, which 
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had to be explicitly referenced. Furthermore, if more than one of the varying entities is to 
be pointed at. the referencing entity had to include all options of the available varying 
entities in its definition. In addition, when changing the inheritance scheme (adding or 
removing a variant entity under the common base entity) all referencing entities had to 
5 be modified to systematically reflect the change. 

In the present invention, since meta-level already includes all relations of a 
referendng entity with all other entities with which it has defined inheritance relations, the 
referencing entity needs to define only a single reference to the appropriate common 
base entity. Consequently, when refening to a certain base entity all its inheriting 
10 variants are all acceptable. In addition, this also implies that when making changes in 
the inheritance scheme no additional modifications of the refemng entities is needed. 

Encapsulation defines behavior of an entity without the need of an extemal 
authority (i.e. each entity contains all of its data, functions and properties). 

In the past the programmer had to write a specific code for validation rules, value 
1 5 limits, default values, and other properties for every form ttiat referenced an entity, ttius 
the quality of the product was largely dependent on the quality of the programmer. 

In Uie present invention, all PerDB-objects (in accordance with object oriented 
programming) encapsulate their own features, thus systematically reflecting these 
features in every form. 

20 An Interface is a predefined set of features. When entities are related to 

interfaces they each define a "can" and/or "has" relation. For example, some chairs are 
stackable and tiierefore "can" be stacked- When implementing an interface (e.g., 
"stackable") in different entities (e.g. chairs, plates, boxes), it is possible to 
synchronically ti^t ttie implementing entities in a polymorphic manner in spite of their 

25 othenvise apparent mutual exclusiveness.. 

The basic framewori^ of the present invention consists of defined building blocks 
(I.e., PerDB-objects) with predetermined characteristics and behavior patterns, and their 
organization on top of it (through its IT professionals or other professional help) can set 
up an ERP application (end-application), to be used by the end-users - them being 
30 administiBtors, woricers and clients alike, according to the specific organization's needs. 
This approach allows each organization to take this basic framewori< and hamess it to its 
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managerial needs and purposes, instead of turning to highly skilled, yet out of the 
organization, programmers for a tailor-made solution. This also means that maintenance 
work is no longer the task of external specialists, who often make their tailor-made 
applications too complicated to be maintained (let alone understood) by others. Instead 
5 the organization can assign its own wori<ers to maintain the system, and fix problems, as 
these occur. Note, that problems may occur, as the end-application is designed by 
people for use by people. The inventors of the present invention stipulate that after a 
reasonable learning period, the basic framework will become a powerful, yet easy-to-use 
tool, which would render the organization managers firm-yet-flexible opportunities to 
1 0 exercise leadership in a teaming organization that Is free of extemal restrictions imposed 
by tailor-made solutions. 

The ERP application based on separation of perception from data is based on 
three primary concepts. In the preferred implementation, these are PerDB-objects 
implemented as database tables comprising records. It will be recognized by one skilled 
15 in the art that they could equally be implemented in other programming formats, for 
example as objerts in a high level programming language. 

The three PerDB-object tables are: 

(A) Tree tables constructed of Tree-Node records. 

(B) Entity tables constructed of Instance records 

. 20 (C) Collection tables constructed of Joint records 

As mentioned, perception in the present invention is taken to comprise four 
degrees of freedom. To implement these degrees of freedom Tree-Nodes comprise fixed 
definitions (see the tree Fixed Columns, FIG 2) assembled in four pseudo-blocks. There 
25 is also a fifth pseudo-block that serves as an operational component. 

In a Tree-Node the Tree-Node's verbal tagging ambiguity may be reduced to 
minimum with the following fields: 

NodelD: A permanent reference to a perceptual item. This is a notation 
tiiat will never expire as long as the organization exists. A deletion of a perceptual item is 
30 never executed physically, but rather handled by Its status flag, associated wiOi the 
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"Since" and Till" fields (see below). 

LabeI_H: The common verbal notation commonly used within the framework of 
the local language (H stands for "home", and refers to the native language of the users - 
the present invention was invented in Israel, and the actual application that was built was 
5 in Hebrew). 

Label_E: The English translation of the common notation of the perceptual 
item (E stands for "English"). Translation to English (or other reference language chosen 
for the system) provides a considerable reduction in the verbal ambiguity, as sometimes 
the same wonJ in a certain language has several meanings. Consider, for example, the 
1 0 word "chair", which may be a piece of fumiture but also a description of an appointment. 
In most cases, when switching to a second language this duality is lost, as for each of 
these meanings is a separate word in the other language. Though this field primarily 
serves to reduce verbal ambiguity, it also constitutes a pivot for multi-lingual applications. 

NodeType; A nomenclature notation taken finom the organization's terminology. 
15 NodeType points to a system tree which embodies all key words that had been used or 
are anticipated to be used by the organization (see Org Nomenclature Tree T004, FIG 
1)- 

In cases, such as this, where a field points to a tree, the user interface can 
include a combination box or drop down list that displays the tree in 
20 contracting/expanding mode (sometime referred to as ComboTreeBox for short). One 
method for doing this is to display initially the top level nodes w\h an indicator whether a 
node has children and where the user can select the node to open the next level of the 
tree in the list. 

In a Tree-Node, the Tree-Node's order in the Tree hierarchy is indicated by the 
following field: 

NodeOrd: This can be a string that follows legal notation (i.e., n.n.n), wherein 
the numeration indicates the branch and level. For example, value 2.1.3 indicates that 
the Tree-Node is on branch 2, sub-branch 1, and sub-sub-branch 3. 

The quantity of possible branches (sibling nodes) and generations (children 
nodes) in a tree is effectively limitless, and may vary according to subjective opinion of 
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personnel within different organizations. A Tree-Node's characteristics trickle down to 
successive tree-nodes (nested children). Once a down the tree-node is attributed a new 
characteristic that overwrites the previous value and is inherited (in the same procedure) 
by its own successive (down stream) tree-nodes. In this way tree-specificity is defined as 
the oveniding of a higher generation characteristic with respect to lower generation one. 
Tree-specificity is restricted to within a given tree branch. Inter-branch specificity 
requires careful Tree-Node assodations which will constitute a virtual tree structure that 
would produce the same specificity pattern. 

A Tree-Node position on a perceptual tree is flexible. Tree owners are free to 
move a Tree-Node from any point to any other point on the tree anangement. When a 
Tree-Node is moved elsewhere in the tree, it retains all its features except the 
hierarchical meanings that is derived from its new position. 

In a Tree-Node, the tree-node's evolutionary qualities are treated by the following 

fields: 

ID: The key field (i.e., DB tenninology) of the Tree-Node record. Unlike 
NodelD. which remains unique for that Tree-Node for the lifespan of the organization, 
the ID identifies the Tree-Node as it pertains to a given time window. A time window is 
defined as the time period within whi<* all of the Tree-Node's parameters (i.e., content of 
fields) remain the same. A change in any field is considered a change in the Tree- 
Node's status; therefore a new time window is created. 

Since: The point in time (date:hourmlnute:second) of the beginning of a 

new time window. This value is updated automatically by the system. 

Till: The termination time (date:hourmlnute:second) of an existing time 

window. This value is updated automatically by the system. 

NodeStatus: The meaning of the field depends on the enterprise's organizational 
policy and/or style. Hence, the values of this field are taken exclusively from {i.e., 
pointers at) the Status branch of the organizational nomenclature tree (see Org 
Nomenclature Tree T004, FIG 1) the same tree used for NodeType. 

Various perception trees can be constructed for the same body of data. In this 
way, an organization may hold to an official view {i.e., a perception tree held by an 
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appointed user or user-group) as well as an unlimited number of individual views (/.a, 
private perception trees) of authorized personnel. 

In a Tree-Node, the ownership of the Tree-Node is a property that is handled 
within the compartmentalization (i.e., accessibility and security) block by the following 
four fields: 

Editor: The owner of a node can be either a certain individual or a user- 
group, which eventually holds a list of certain individuals. The value of this field is 
checked against the PerDB-login details of the user. A user who holds action privilege 
status of edit or higher (such as delete, insert, initiate) to a Tree-node, may become a 
Tree-Node Editor holding exclusively all privileges derived from the tree-node's fields 
and data pointed at. Editor rights trickle down hierarchically the perceptual tree. Each 
time a new editor is specified within a tree branch, it implies that an editor is delegating 
editor authority of the new individual to that node, its offspring nodes and to the 
infomiation entities on which they point at 

DataSec: This field is meant to limit accessibility to the Tree record by 
indicating the accordance of the nature of data contained in the Tree record with regard 
to a given type or essence of organizational data as specified on the Data Section Tree 
(T006, FIG 1). The DataSec field exerts the data-type conflation holding a pointer at a 
proper certain Tree-Node of the Data Section Tree. It goes without saying that this data- 
type correlation pertains to all children Tree-Nodes of the pointed at Tree-Node (i.e., 
sometimes related to as a tree branch) of the Data Section Tree too. It should be noticed 
that the data-type conrelation pertains only to one particular branch of the Data Section 
Tree, Would there raise a need to pertain to more than one nested branch of the Data 
Section Tree, the IT personnel should consider the construction of another adequate 
hierarchy of branches. 

SubOrg: This field is meant to limit accessibility to the Tree record by 
indicating the pertinence of data contained in the Tree record with an appropriate 
subsection within the organizational echelon. The content of this field is a pointer at a 
Tree-Node of the Organization Manning Tree (T006, FIG 1). Here again, a pointing onto 
an organizational node means that particular section and all of its suborclinating ones. 

Protected: A Boolean value which distinguishes between infomiation items 
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deemed absolutely necessary for the proper functioning of the system, and those items 
which are in the responsibility realm of the organization (i.e., its IT personnel or laymen 
users). 

Properties: A technical field that is used for the introduction of macro 
5 procedures that are primarily meant to exert specific functions on remote Tree, Entity 
and/or Collection fields. 

The prime essence of the perceptual tree is to approach raw data by the 
adequately permeable perceptual parameters and filters, as depided above. This goal 
10 is reached by the data block fields, as follows: 

Data: If the perceptual node is aiming at a single infonmatlonal item. In 

case that it consists of a single data (e.g., a string, a number, a time point, etc.), a 
quantity {I.e., numeric value coupled to a series of dimensions) or a statistical product 
(e.g., number of instances, sum, etc.), then this field would hold the infomriative data 
1 5 itself in the appropriate syntax. 

In the case that the node record is refemng to another record (i.e., Tree-Node, 
Entity Instance or Collection Joint), the "Data" field will hold a string address, which 
PerDB interprets as a pointer onto the specified record. 

In the case that the node record is referring to a Collection Joint, PerDB 
20 recognizes that this pointer refers actually to the assembly block of target records as by 
the definitions of the auxiliary Collecb'on table (see L014, FIG1). 

DataType: As can be appreciated from the preceding paragraph, "Data" fields 
may hold a series of expressions, each of different syntax and a different essence. In 
order that PerDB system would property interpret the content of the "Data" field, it 
25 requires an adequate indication. This is achieved by the DataType auxiliary field, which 
is by itself a pointer onto the "Field" branch of the organizational nomenclature tree 
(T004) that may include (see FIG 2): 

Self Values, such as (but not limited to) text, memo, object, Boolean 
expression, time, date, time & date, time window, date window, 

30 Numbers, such as (but not limited to) Integer, automatic numerator, real 
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number, percent, quantity; 

Dummy field, which is an empty of content auxiliary item. 

Statistic products, such as (but not limited to) counter, counter + sum, 
counter + mean value, counter + mean value + SD value (standard deviation); 

5 Pointers, selected from the three types of pointer (see above) plus a 

TreeBranch pointer used for tree-tree assodation; 

Execution button is a trigger for activating a macro procedure, 

Due-Day Alert Is a trigger for an alert message to be activated on the firet 
occasion following the date and time specified. 

10 DataSrc: This field is an auxiliary field aiming at assisting the IT personnel 

by limiting the span of search in a Tree table, depicted for the IT in the ComboTreeBox, 
to the appropriate branches of the organizational nomenclature tree within the relevant 
indication of the "DataType" field. 

Raw data accumulates in storage tables designated "Entity", whose records are 
1 5 refered to as "lnstance"s. 

Entities are created and designed as derivatives of the Entity Heritage Tree 
(T001, see FIG 1), in a fashion parallel to the fomnation of a new child-node. It permits 
the user to fomriulate complex assemblies, diversely appending a variety of entities to a 
base entity, hence gaining the object-oriented quality of polymorphism of the "is a" 

20 relation. For example (see FIG 5), the Entity records of rooms/worldng spaces of a 
sophisticated organization, such as a higher education teaching institute, are efficiently 
organized in an object-oriented cascade framewori^. Under such a scheme ttie record of 
a computer classroom will be split among the base instance of "a space" table, and the 
extending instances "a room", "a classroom", and "a computer classroom" tables. Each 

25 instance holds certain specific fields at ttieir proper specialization level. The parallel 
record of an office will be split among "a space", "a room" and "an office" instances, 
respectively. 

Entity Instances may also be coupled with complementary Interface instances, 
which contain information shared witti ottier unrelated Entities, in an object-oriented 
30 polymorphism of Uie "can" and/or "has" relation. For example, mailing infomiation may 
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be encapsulated in certain Instances in the appropriate Interface, Then, this infomiation 
can be implemented by coupling it with a variety of entity instances that have a mailing 
address by themselves. Beyond the efficiency of this polyphormic mechanism, over the 
repetitive fields in every Instance, Interfaces facilitate readily co-gathering of various 
5 Entity Instances according to the shared implemented information. 

Entities (interfaces included) employ a series of control components that should 
take care of three types of systematic perfomiances: 

(A) Expression of proper compartmentalization flags. 

(B) Self-orientation (object-oriented like and neural-networic like) within the 
1 0 bulk of information. 

(C) Validation of appropriate content (i.e., type of data) and functions (i.e., 
pointers and macros) of the instance fields. 

To comply with these systematic demands, an Entity Is coupled to two series of 
meta-definitions (see FIGs 3 and 4) and to a series of administrative fixed columns (see 
15 FIG 2). Both meta- and administrative components are used Ad Hoc by PerDB 

Interpreter for its run time procedures. These meta- and administrative definitions serve 
as substitutes to the commonly used code for controlling the behavior of ordinary ERP 
applications, thus, facilitating seamless and immediate responsiveness to regulatory 
modification within the authority of the organizational IT personnel. 

20 The first level meta definitions attributed to the Entity level can be edited by the IT 

in the "Entity Meta Editor E012" Entity (see FIG 1). Upon approval of the meta-definitions 
values (as stated in E01 2 fields), they are transfonmed to control mode and transfen^d to 
the "Entity Meta List L012" Entity by an appropriate macro procedure (see FIG 1). PerDB 
perfomnance is controlled according to the definitions found in L012 fields at each 

25 execution. 

The Entity meta-table level comprises entry parameters made of the following 
components: 

Entity_CN: The notation name of the Entity comprised of a prefix E or I (for 
Entity or Interface, respectively) followed by a unique three digit number (e.g., E020, 
30 E1 01 . 1431 ) drawn from the "Table Numerator L01 1 " (see FIG 1 ). 



23 



wo 2006/016350 



PCT/IL2005/000693 



24 

Label_H: The local home-Language verbal name of the Entity. 

LabeLE: The English translation of the Entity Name. 

The accessibility issue is taken care of at the Entity level by the following 
Components: 

5 DataSec : A pointer at a certain Tree-Node of the Data Section Tree (T006. 

FIG 1) which serves as an indication that the content of the Entity table pertains to a 
given type or essence of organizational data in a manner similar to that of the DataSeo- 
field effect in the Tree-Node record (see above). 

SubOrgFietdCN: An auxiliary field that is meant to assist the IT personnel in 
1 0 way of providing a default value for the herein SubOrg field by drawing a certain remote 
SubOrg field content. 

SubOrgOvenide: A second auxiliary field that is meant to assist the IT 
personnel in way of providing a certain default value for the herein SubOrg field. 

Entity table complies with the system consistency demands (PerDB enforceable) 
15 in accordance with the following control meta-fields: 

Abstract : A Boolean indicator for the fact that the Entity cannot initiate 
Instances on its own. Consequently, the IT is prevented from creating/initiating any 
Instance to the Entity. It rather serves as an intermediate generation in the Entity 
heritage cascade, as by the object-oriented standards. 

20 Final: A Boolean indicator for the fact that the Entity is the last of a heritage 

cascade (i.e., no Instance can he inherited from the Entity) 

CN J (CN stands for "common name"), i serves as a numerator used by PerDB in 
automatic naming of new Fields. 

CollectionJ is a parallel technical field for regulating the automatic formation of 
25 new collections. 

DenyDendrites A Boolean indicator for the fact that the Entity does not 
require knowledge of who points at him. 

Abstracts A vector {i.e., an anay) of Interface tables that are implemented by 
the Entity. 
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Subsequently to the Entity meta-table parameters, which serve as control 
indicators for PerDB gate for entering the Entity as a whole, PerDB requires indicatore 
for functioning at the proper resolution within the entity's rows (i.e. Instance) and 
columns matrix. Accordingly, additional control parameters are provided in the two 
5 fomnats: the Administrative Fixed Columns (see FIG 2)., which pertain to the rows' 
control; and Column Meta-Definitions associated with the Instance's Data Columns (see 
FIG 2) which pertain to the Entrt/s column control. 

Administrative columns are meant to supports the PerDB proper systematic 
interpretation of Entities (Interfaces included) v\rtth regard to: 

1 0 (A) Setf-orientation (both object-oriented like and neuron net-work like) within the 

bulk of information, 

(B) Affiliation to sub-organization echelon (as first compartmentalization flag). 

(C) Implementing adequate Interfaces. 



1 5 The orientation issue is supported by the following five fields: 

ID : An identification of the Instance. 

UpRn A pointer at the preceding instance in the object-oriented heritage 
cascade. 

DownPtr: A pointer at the successive instance In the object-oriented heritage 
20 cascade. 

Dendrites: A series (/.e.. an anay) of redprocal pointers at all other Tree- 
Nodes, Instances and Joints which point at the Instance (Vho points at me?"). This 
neural-networi< like parameter is meant to keep the systematic Integrity of the data body. 
In addition, it serves as a safety tool that should prevent the deletion of an instance that 
25 is needed for the proper functioning of otiier parts of tiie system. In should be noted tiiat 
this feature renders the present invention neural-network qualities, hence permitting 
accessibility to a desired point in the data from any relevant entry-point within the data 
body. 

The affiliation to the sub-organizational echelon is supported by the field: 
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SubOrg : A pointer at the Organization Manning Tree (T006, FIG 1 ) bearing 
identical features to those specified for Tree's and nneta-Entit/s SubOrg fields (see 
above) . 



The implementation Interface Instances is supported by the field: 

Interfaces : A sequence {he., an array) of Interface-Instances in accoixlance with 
the Interface sequence specified in the Entit/s meta-definitions (see "Interfaces" meta- 
field, FIG 3). 



10 The infonnation columns of the Entity may hold a spectrum of data types and 

syntax. It reflects the notion that PerDB supports the storage of not only plain strings 
and numbers, but also quantity values {i.e., a numerator coupled with its dimension) and 
pointers at every possible Tree-Node. Instance and/or Joints. To comply with that 
versatility, an Entity infomiative column is contix)lled by a series of characteristics, which 

15 are initially edited witii Uie aid of the Column Meta Editor E013 (see FI61) by the 
organizational IT personnel. Upon approval the parameters are transformed into control 
mode and transferred by an appropriate macro procedure to the L013-Field Meta List 
(see FIG 1). 

The series of the Entity meta-Ck)lumn parameters are assembled in four pseudo 
20 group of configuration fields. 

The first group of fields serves to identify the name of flie data column by the 
following characteristics: 

Table: A reference to the Entity or Interface table name in accordance 

with the table specified on the Entity Meta List L012 (see FIG 3). 

25 CN: The column "Common Name" of the field comprised of a "CN_" 

prefix and a numeric index derived from the "CNJ" meta-field of the Entity Meta Ust 
L012 (see FIG 3). The common name is the column reference used by PerDB 
interpreter. 

LabeLH: The field's humane alias of the column in the local home 
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language. 

LabeLE: The field's humane alias in English. 

The second group of fields comprises meta-fields aimed at facilitating the 
5 appropriate usage of the Instance record. To start with, an Instance may hold an 
unlimited number of infonmative fields, however, it is reasonable to assume that it can 
(and should) be acknowledged by a short display of only some certain representative 
"leading fields". For instance, In most cases at which a person would have to be 
addressed, it is reasonable that a display of his first and family names will suffice (no 
1 0 need to specify his Civil ID, gender, age etc.). Accordingly, the Entity field is coupled with 
the meta-field: 

LeadOrd: An integer value that implies a status of a leader* field and 
indicates its order of appearance in short displays of the Entity record. Subsequently, 
these fields are made available for instance filtering and sorting on the input/output 
15 automatic forms and/or reports. A null value will indicate that such a field should not 
appear in any short display of the record. 

The other control characteristics are: 

FieldType: An indication of the type of data that PerDB interpreter should 
expect in the instance field. The indication is actually a pointer onto the branch "Field" of 
20 the organization nomenclature tree (parallel to the DataType field of a perceptual tree). 

FieldSrc: The address pointing at. The value for this meta-field is expected 
to be drawn in two stages. First, to choose the relevant table {i.e.. Tree, Entity or 
Collection) from a Comtx)Tree-Box, in which the appropriate branches of either the Tree 
List or the Entity Heritage Tree will be depicted. Then, the instance will be chosen from 
25 the display of the table pointed at 

SubSrc: An auxiliary field that is meant to extract for display only 
appropriate branches of the FieldSrc selected Tree which will appear thereafter in the 
FieldSrc ComboTree-Box. 

Mandatory: A Boolean indicator for the absolute demand (of the IT) for an 
30 updating value once the Instance is processes by the Automatic Input Form. 
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The third group consists of a single paranneter. that is the complementary 
compartmentalization characteristic (i.e., orthogonal to the Administrative SubOrg) is 
spedfled in the field 

DataSec: An indicator to the nature of the data expected in the column. 
5 Independently, the meta-column DataSec serves to fonm the field lines (i.e., "information 
sentence") in the Automatic Input Forms and/or Output Reports. That means that the 
automatic input/output devices display sequential lines each comprised of a series of 
instance fields that are characterized by the same DataSec value. The order of lines is 
detemiined by the branching order of the DataSec values on the Data Section Tree 
10 (T006). 

The forth group of the meta-column fields aimed at enabling PerDB to perform 
adequate data manipulation at various phases of operation. This group comprises the 
following fields: 

ValueLimits: A series of expressions that constitute infomiation used by 

15 PerDB for data verification according to predetermined string structures and/or quantity 
values. 

DefaultValue A predetennined string or value that will be put into the refen^ed 
field whenever a new instance shall be initiated. 

OnChange: Macro syntax to be activated upon changing the filed value 

20 while operating on the Automatic Input Form, prior to loading the changed values onto 
the database. 

OnUpdate: Macro syntax aimed at manipulating data content of the 

field referred and/or data of remote fields upon updating the referred filed value. 

Properties: A vector of additional properties that may be associated 

25 with any field and that are interpreted by the PerDB at run time of the automatic device 
or within database transactions. 



A "Collection" is a device whose records, {I.e., Joints), match a single record of a 
Tree, an Entity or another Collection (designated "Source") with either a series of values 
30 or a series of other records (designated "Targef ), 
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Collections may be employed for multi-mutti relationships between Instances. 
Hence, Collections becomes a suitable dispatching recorder, or a highly efficient bi- 
directional manning reporter. 

To meet the Collection task, it is constructed of two administrative and two 
5 functional fixed columns. The administrative fields are technically identical to their 
parallel Entity ones: 

ID: The Joint identifying field 

Dendrites: The reciprocal pointer vector that records all records that point at 
the joint excluding the source instance. 

1 0 The fixed columns are: 

Sid: A pointer at the source instance. That is, the instance that initiated the 
connection to the series of targets. 

Tid: This field can be used as either a single value, or a pointer at another 
single record. 

15 

PeriDB handling of the Collection Joints require the meta-characteristics as 
defined in the "Collection Meta Configuration" L014 list of fields: 

CollectionCN: The Collection's Common Name used by PerDB consists of a 
prefix of the letter "C" followed by the numerator of the table (i.e., Tree, Entity or 
20 Collection) whose record (i.e., Tree-Node, Instance or Joint) is the source of the coupling 
indicated in the herein references Collection's Joint, and followed by a "J" numerator in 
accordance with the "CollectionJ" field of the "Entity meta Configuration" L012 (see 
FIGsland 3). 

SourceType: An indication to the nature of the Sid field content. It is a 

25 pointer to the "Field" branch of the organizational nomenclature tree (T004). 

SourcelD: An indicator for source table pointing at Bither the Tree of Trees 
TOOO, Entity Heritance Tree T001, or the Collection Meta Configuration L014 ID fields in 
the case that the initiating record is either a Tree-Node, an Instance or a Joint, 
respectively. 
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SourceCN An pointer at the common name of the field that particulariy 
initiated the herein Joint. This indicator Is relevant only in the case that the Joint is 
initiated by an Instance, which may include several fields that initiate a variety of 
independent Collection Joints. 

5 TargetType: An indication to the nature of the Tid field content It is a pointer to 

the "Field" branch of the organizational nomenclature tree (T004). 

Target: If the TargetType contains a pointer indicator, this meta-field will hold the 
address of the record pointed at If the TargetType contains the "Quantity" indicator, this 
meta-field will hold the dimensions coupled to the particular parameter. 

10 

PerDB interpret data elements (e.g.. Tree-Node's Data Column, Entit/s data 
Columns and Collection's Tid Column) as follows: 

Quantitative elements: 

Scalar: A number, integer or real value (such as 2, -1 .5, 3.43, etc.). 

15 or a logical expression (such as >5, >=7, etc.). that yields a Boolean value of true or 
false (e.g. 1 or 0 respectively). 

Quantity: A scalar followed by a unit vector fomiulation 

(*unit/unit..). Units are defined by the "Dimension" branch in Org Nomenclature Tree 
T004, for example 1200*199/437/968 stands for (in the Tel Hai Academic College's 
20 Nomenclature Tree/dimension branch) 1200 New Israeli Shekels (Israel's cunency) per 
semester per student 

Field content An arithmetic value that is called by the syntax 
[TableCN].[FieldCN], where pTableCN] may refer to an Entity or refer to an interface (as 
in the Entity Inheritance Tree [T001].[data] ). An arithmetic field is restricted (as 
25 detemilned by Its meta-deflnltion) to [RIedType] = integer, real, quantity or Boolean 
value. 

The [TableCN] is mandatory for fomis comprised of more than one entity record, 
which are conjugated by inheritance. If the [TableCN] has left out a default [TableCN] 
(i.e. the table of the current field considered) is added (e.g. [CN_0]. [E026].[CN_0]). 
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Dynamic association elements - pointers of data fields on records: 

The ability to point on a record is restricted to the following fields: 

<tree node>.[data], <entity>.<data fields>. <collections>,[nd], and is regulated 
by one of the following Pointer Tenns (taken firom the Org Nomenclature Tree T004): 
Node Pointer, Instance Pointer, Joint Pointer. 

A pointer syntax is in the fomn of: [TableCN].[ID].<extension>. 

The Instance Pointer (the extension is ineffertive): This pointer retrieves leading 
data fields by their LeadOrd meta-values. These fields are readily available for sorting, 
filtering and similar functions, and also used for triggering full instance expansion. 

The Joint Pointer (the extension is ineffective): This pointer retrieves the Tid field 
content, be it a self-value, a joint or even a pursuing pointer. 

The Node Pointer (for this pointer the extension is effective): This pointer 
retrieves the Label (either Label_H, or Label_E, according to the chosen language of the 
user-interface). Data field content is governed by constraints by the rest of the regulatory 
technical fields of the Node. 

An Extension may take one of the following fornris: 

.NodelD - Retrieves the Data value of the record identified by NodelD. 

-LatestlD - Retrieves the Data value of the record which is the latest update of 
the record that holds an identical Nodeld value to the record identified by the ID called. 

In the absence of an extension the plain ID field is considered as a default 

PPDO (/.e., People, Perceptions Data and Operations) is a perceptual approach 
to infonnation management that makes use of PeriDB objects and interpreter engines. 
PPDO is a product that starts its life as a minimal series of manufacturer supplied 
system-trees and auxiliary tables (sometimes refeoBd to as PeriDB-Kemel). System- 
trees' Tree-Nodes are tagged "Protected", hence, remain strictly unchanged for the 
lifetime of the system and thereby continuously support proper PerDB functioning. 
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Authorized IT personnel are provided with full capacity to specifically customize their 
application. They are free to point at the system Tree-Nodes and are encouraged to 
expand the same system-trees by additional branching, as well as constructing new 
ones by the organization needs. 

5 The PerDB-Kemel comprises the following objects (see FIG 1 ): 

Tree of Trees TOOO: A perceptual tree, whose nodes depict the 

hierarchical arrangement of all PPDO trees. Tree of Trees table is the tool by which 
authorized IT personnel can initiate new trees {i.e., by creating child nodes), then move 
onto the tree referred to for editing or deletion according to their privileges. 

10 Entity Heritage Tree T001: A tree that depicts the heritage relations between 

Entity tables. It serves also as the first phase in the mechanism of initiating Entity tables. 

Input Procedures' Tree T002:A tree that organizes Automatic Input Interface 
forms in a logical (i.e., a perceptual) order so as to permit laymen users to easily retrieve 
a desired input form, to adivate Its associated procedures (e.g.: macros) that facilitate 
15 inputting data in format of infomiation sentences detemiined automatically accorxJing to 
the Data Sections Tree fT006) hierarchy. 

Output Procedures' Tree T003: A tree with parallel features to those 
ascribed to the Input Procedures' Tree. 

Org Nomenclature Tree T004: A minimal series of tenms necessary for 
20 proper PerDB interpretation of PPDO itemization. Hence, prior to the submission of this 
tree to PPDO customization (i.e., PPDO-Core), it is filled with certain protected 
branches: 

(A) Generic user groups 

(B) Privilege level of data manipulation 

25 (/.e., hidden, read, execute, write, change, delete). 

(C) Statuses 

(D) Dimensions 

(E) System-Definitions. 
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IT personnel may clearly use these nodes but never edit or delete them. On the 
other hand, IT personnel are free to add further specific generations to the same 
branches to meet their needs. 

Data Section Tree T005: A tree that compartmentalizes the various definitions of 
5 the nature of the organizational data, in the form of predetennined sections. Final nodes 
in the Data Section Tree define a single elementary unit for security and privileges 
handling, and are also used for automatic division of input forms into paragraphs 
comprised of information sentences (series of fields sharing a common meaning and/or 
nature). 

10 Fields are tagged with DataSec value. Grouping Is done at run time. The 

DataSec node in the tree has no knowledge of its consumers. 

Manual/Help Navigator T010:An optional, yet highly recommended tree for it 
offers explanation and help to programmers and users alike. Tree-Nodes point at 
relevant instances of Manual/Help Item E021. 

15 The graphic PPDO editor points to two entities: E012 - Entity Meta editor (for 

draft editing Meta Entities, this is a programmers or IT personnel tool), and E013 - Field 
Meta editor (for draft editing fields, again this is a programmers tool, for setting up an 
ERP application, and not to be used by the end user). 

At the end of an editing sequence, both these Entities are translated by PerDB 
20 (e.g., macros) to three control lists: Entity Meta List L012 , which holds the Entities' meta 
parameters, Field Meta List LOIS, which holds the Fields' meta parameters and 
Collection Meta List L014, which holds the collections meta parameters that are drawn 
from the collection originating Entity Fields' meta characteristics. Table Nominator L011, 
is an auxiliary list of numbers used to assure exclusive assignment of table indices to 
25 Trees, Entities and Interfaces. 

The PerDB-Kemel is in fact a programmers (or IT personnel) tool, for this is the 
infrastaicture of the ERP application in accordance with a preferred embodiment of the 
present invention. 

A practical ERP application in accordance with a preferred embodiment of the 
30 present invention suitable for adaptation for any organization requires an expansion of 
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PerDB-Kemel. Any organizations who exercises information compartmentalization, 
needs to inform PerDB on its personnel, suppliers and customers accessibility privileges. 
Accordingly, PerDB-Kemel is supplemented with a minimal set of tables (combined they 
are sometimes refenBd to as PPDO-Core, see FIG 6). 

In addition to tiie PerDB-Kemel (see FIG 1) the PPDO application requires basic 
infonmation on the organization manning definitions and the compartmentalization 
parameters of the organization's registered personnel, suppliers and customers. 
Accordingly PPDO-Core comprises the following tables (see FIG 6 central box) 

Org manning Tree T006: The hierarchical presentation of the manning of the 
organization echelons. One should keep in mind that PerDB, and consequentiy PPDO, 
are infonnation managing applications. Thus, the Tree-Node of the Org Manning Tree 
should not report merely the echelon's judidal state, but rattier depict all types of its 
manning (i.e., personnel, suppliers and customers). For the sake of suitable information 
compartmentalization, special emphasis should be made wth regard to the broadening 
and nanowing (/.a, generalization vs. specialization) of tfie Tree-Node hierarchy. 

Org Job Tree T021: The categorization of all types of jobs within the 

organization. The categorization resolution should reflect the information gathered on the 
appointees, and tiie infonnation that ttiese appointees are expected to have accessibility 
to. Each T021 Tree-Node points at a certain Job Definition Instance: 

Job Definitions E022: The detailed description of a job in temns of responsibilities 
and interactions witii other organization appointees as well as out of the organization 
suppliers and customers. Each job definition Instance is connected via Collection 
C022_0 to a series of privilege definitions: 

Job Privileges E023: A pointer at a Data Section Tree (T005) branch coupled 
with a pointer at an Action Privilege branch of the Org Nomenclature Tree (T004). Each 
such couple defines two (out of three) comparbnentallzation flags. Accumulative 
privileges of a given job are grouped witti ttie aid of collection C022_0 in a one-to-many 
reference. The ttiird compartinentalization (i.e., SubOrg) flag is atbibuted to an 
appointee as by its organizational assignment 

Person Card E025: An an^y of data fields tiiat identify the persons 

witiiin the organization. Usually it comprises the person's name, civil ID number, 
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organization's ID number, and sometimes, the computer account User-Name and 
cunnent password. A Person Card is intemriittently coupled with: 

Personal Item Card E026: An expansion table which includes 

complementary details of the person as by the organization policy. Except for pointers 
5 on all appointments of the referred person are absolutely necessary for proper PPDO 
customization, in particular, for data compartmentalization. A person may hold one or 
many appointments in the organization. Accordingly, the Personal Items Card is 
connected via Collection C026_0 to a series of: 

Appointment E027: An array of pointers that define first a job (i.e. 

10 pointer on T021), which is automatically linl<ed to the appropriate Job Definition and 
series of DataSec times Action Privilege parameters. Second, it specifies the affiliation 
(i.e., a pointer on a single T006 Tree-Node) in context of which the job is defined, thus, 
indicating who hired that person (i.e. who is/are his superior/s). Finally, it defines the job 
organizational jurisdiction (i.e., a series of pointers on T006 manning group braches) in 

15 tenms of who that person is responsible for (i.e., who is/are his "organizational 
customers").. 

Unlilce the PerDB-Kemel tables, the PPDO-Core complementary tables are 
provided empty of content Since the latter is a pure reflection of the organization's 
specific way of operation. Nonetheless, their crucial task in putting PerDB to wori< (i.e., 
20 PPDO customization) requires flie attention of IT personnel at the very early stages of 
their system construction. 

The following explanation goes into explaining the present invention in greater 
detail, by way of example, based on a wori<ing basic framework that was built by the 
inventors of the present invention to serve as the administi^tive management system for 
25 the Tel-Hai College (in Norttiem Galilee, Israel). This application was built based on 
Microsoft's MS-SQL platform, but Uiis is of course not mandatory, as the present 
invention may be implemented on other T-SQL supporting platfonms too. 

FIG.7 illustrates a module of an ERP application in accordance with a preferred 
embodiment of the present invention that was designed for The Tel-Hai Academic 
30 College Martceting department 

This module alms at assisting The Marketing Department personnel process 
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Student Application that enter the system either by a web based self application, offering 
applicants the chance to apply to the college via the internet, or by an agent who types 
the data in while having verbal communication with the applicant. 

On the first route, input is made into Self Application Entity E179 using an AST 
5 from accessible on the Tel Hal Academic College web site. A process (macro) is initiated 
for transfemng the data into an Applicant Card E175, so that Tel Hal personnel could 
inspect and approve the information from an adequate Tree-Node of the Input 
Procedures' tree T002. The Applicant Card E175 points at the status branch of the Org 
Nomenclature Tree T004/staus branch to extract an Applicant Status value. An 

10 Applicant Card persists for the system life time, hence, it is connected to many 
Application Card E176 via collection C175_0, which represents a single dialogue 
(session) between the applicant and the Tel Hai Marketing Department, inrelevant of the 
dialogue mode (i.e., internet, phone call or letter). The Application Card E177 points to 
three branches of the Org Nomenclature Tree T004 to extract an Application Status 

15 value, an indication of who recommended the college to the applicant, and an indication 
of mode of communication employed by the Applicant to execute the application. During 
an application session a series of Applicant's subjects of interest could be uploaded to a 
Subject of Interest entity (E177) with Uie aid of Collection C176__0. Subjects of interest 
are specified by pointing to three branches: one exfa^cts a general discipline of interest 

20 from Tel-Hai's Nomenclature Tree T004; the second, exfanacts a department of interest 
from Tel-Hai's Manning tree T006/student branches, and the last extracts a specific 
program of interest from Tel-Hai's Teaching Program Tree T031 . The Application Card is 
also connected, via collection C176_1 to Marketing Response Entity El 78, itself 
connected to Collection C178_0 whose Tid column holds pointers to Tel Hai's 

25 Nomenclature Tree T004/Public Relations (PR) materials branches. 

The above framewortc determines the pattem of data collection. It is an exclusive 
scheme that Is unequivocally interpreted by PerDB in offering the Marketing Department 
of the college personnel Automatic Input Forms while holding the dialogues with the 
applicants. Notice that the Marketing Department personnel may enter the scheme at 
30 any relevant point, be it with registering a new applicant, or be it an opening of a 
successive session wiUi an already registered applicant, or even a general entry to 
subject of interest or list of responses canried out by the Marketing Department 
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Personnel. In any such entry the neural-network properties of the instances (i.e., 
"Dendrites" values) would automatically trigger the opening of relevant upstream 
information (e.g., for an entry of either Subject of Interest or l\1arketing response 
indications to the relevant Application and Applicant Cards vi^ll be displayed). 

5 The example shown In FIG. 7 demonstrates the universal appeal of the EPR 

application of the present Invention, v^ich Is in fad a flexible tool that may be adapted to 
any organization and serve it property. 

It should be clear that the description of the embodiments and attached Figures 
set forth in this specification serves only for a better understanding of the invention, 
1 0 without limiting Its scope as covered by the following Claims. 

It should also be dear that a person skilled in the art, after reading the present 
specification could make adjustments or amendments to the attached figures and above 
described emt}odiments that would still t>e covered by the following Claims. 
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CLAIMS 



1. A method for a universal Enterprise Resource Planning (ERP) information 
management suitable for any organization, the infomnation separated into raw data and 

5 at least one of a plurality of subjective perceptions attached to it, the method comprising: 

organizing infonDation into tables of three types: 

entity table for raw data, 

tree table for perception , 

collection table for many-to-many associations, 

10 manipulating the infomnation according to a set of predetemnined parameters that 
constitutes meta characteristics of the information, using a set of macros 
to perfomn operations. 

2. The method of claim 1 , wherein the tables comprise a database, 

3. The method of daim 1 , wherein entity table comprise administrative fields 
15 which record inheritance. 

4. The method of daim 1 , wherein entity table comprise administrative fields 
which record redprocal pointing relations. 

5. The method of daim 1 , wherein entity table comprise administrative fields 
which record interface implementations. 

20 6. The method of daim 1 , wherein entity table comprise administrative fields 
which record affiliation to an echelon of the organization. 

7. The method of daim 1 , wherein entity table comprise informative fields for 
raw data. 

8. The mettiod of daim 1 , wherein tree-table comprise records defining tree- 
25 nodes. 

9. The method of daim 1 , wherein tree-table comprise multi-lingual fields. 

1 0. The method of daim 1 2, wherein one of the multi-lingual fields relates to a 
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nomenclature of the organization. 

11. The method of claim 1, wherein tree-nodes comprise fields relating to 
tracking of evolution of the tree-nodes. 

12. The method of claim 1, wherein tree-nodes comprise fields relating to 
5 compartmentalization, 

1 3 The method of claim 1 , wherein tree-nodes comprise fields relating to one 
or many entity or collection records. 

14. The method of daim 1, wherein tree-nodes comprise fields relating to 
tree-node to tree-node association and/or disassodation 

10 15. The method of daim 1, wherein tree-nodes comprise fields relating to a 
cascade of tree-nodes and thereafter relating to their related tree-nodes 
and/or entity records and/or collection records. 

1 6. The method of daim 1 . wherein collection table comprises administrative 
fields holding one-to-one relations between records. 

15 17. The method of daim 1, wherein collection table comprise administrative 
fields holding one-to one relation between a record and a value. 

18. The method of daim 1, wherein collection table comprise administrative 
fields which record redprocal pointing relations. 

19. The method of daim 1, wherein the set of predetemiined parameters 
20 comprises one or more tables. 

20. The method of claim 1, wherein the set of predetennined parameters is 
modifiable. 

21 . The method of daim 1 , wherein the set of predetemiined parameters that 
constitutes meta characteristics is stored in a kernel. 

25 22. The method of daim 1 , wherein the set of predetemiined parameters that 
constitutes meta charaderistics of entities. 

23. The method of daim 1 , wherein the set of predetemiined parameters that 
constitutes meta characteristics of fields. 
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24. The method of claim 1 . wherein the set of predetemiined parameters that 
cx)nstitutes meta characteristics of collections, 

25. The method of claim 1 , wherein the operations also include functions. 

26. The method of daim 1, wherein the operations include automatic 
operators that create or modify tables and further meta characteristics 
using a predetermined editor. 

27. The method of daim 1, wherein the operations dynamically create 
automatic input forms and/or output reports in accordance with the meta 
characteristics. 

28. The method of daim 27, wherein the automatic input fomns indude a 
contracting/expanding tree. 

29. The method of daim 1 , wherein the operations dynamically guard validity 
of data in accordance with the meta-characteristics. 
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